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Comparisons  Between  the  RTNEPH  and 
AFGL  Cloud  Layer  Analysis  Algorithms 


1.  INTRODUCTION 

The  Real-Time  Nephanalysis  (RTNEPH)  is  an  automated  cloud  analysis  model 
that  is  in  operational  use  at  the  Air  Force  Global  Weather  Central  (AFGWC).  In  the 
RTNEPH,  polar-orbiting  satellite  imagery  is  analyzed  in  conjunction  with 
conventional  meteorological  cloud  observations  to  produce  a  global  analysis  of  cloud 
attributes  such  as  extent,  height,  bases,  and  type.  The  RTNEPH  and  its  predecessor, 
the  Three-Dimensional  Nephanalysis  (3DNEPH).  have  been  generating  real-time 
global  cloud  analyses  since  1970  (see  Fye,  1978;  Kiess  and  Cox,  1988).  RTNEPH 
cloud  analyses  are  used  primarily  to  initialize  cloud  forecast  models  in  support  of  Air 
Force  missions,  and  they  are  also  archived  for  use  by  the  research  community  as  one 
of  the  few  sources  of  long-term  global  cloud  climatologies  available  today. 

Infrared  (IR)  satellite  imagery  is  the  primary  and  most  reliable  source  of  global 
cloud  observations  for  the  RTNEPH  because  of  the  frequent  updates  and  availability 
of  the  data  both  day  and  night.  The  RTNEPH  infrared  processor  makes  cloud  cover 
decisions  by  comparing  measured  IR  brightness  temperatures  with  an  expected 
underlying  surface  temperature.  Simply  stated,  if  the  measured  brightness 
temperature  (with  atmospheric  effects  removed)  is  sufficiently  colder  than  the 
underlying  surface  temperature,  cloud  is  detected. 

The  RTNEPH  contains  a  layer  analysis  algorithm  that  combines  pixels  of  an 
8  X  8  IR  satellite  image  into  thermally  homogeneous  groups.  These  groups,  refeired 
to  as  clusters,  form  the  basis  of  the  RTNEPH  cloud  layer  analysis. 
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In  1980.  an  alternative  to  the  RTNEPH  layer  analysis  algorithm  was  developed  at 
the  Air  Force  (Geophysics  Laboratory  (AFGL).  The  AFGL  algorithm  (see  Hawkins, 
1980:  1981)  performs  a  layer  analysis  using  a  16  X  16  array  of  IR  satellite  pixels, 
four  times  larger  than  the  RTNEPH  array  size.  An  early  comparison  study 
(d'Entremont  et  a!..  1982)  showed  that  the  AFGL  algorithm  produces  a  more  realistic 
result  because  of  the  additional  cloud  information  contained  in  the  larger  array.  This 
result  is  obtained  even  though  the  AFGL  algorithm  is  no  more  computationally 
complex  than  the  RTNEPH  layer  analysis  algorithm.  As  a  result  of  the  positive 
conclusions  of  the  early  study,  the  AFGL  cloud  layer  algorithm  was  proposed  as  an 
alternative  to  the  current  RTNEPH  algorithm. 

Although  a  limited  comparison  had  already  been  performed  between  the  AFGL 
and  the  3BNHPH  layer  algorithm  (d'Entremont  et  ah,  1982),  the  Air  Weather  Service 
requested  that  another  more  comprehensive  comparison  study  be  conducted  using  the 
RTNEPH  algorithm.  In  response  to  that  request  AFGL,  in  collaboration  with  the 
RTNEPH  software  group,  developed  test  procedures  for  a  new  comparison  study. 

The  comparison  was  performed  using  case  study  days.  Two  days  were  selected  as 
representative  of  a  wide  variety  of  conditions;  one  from  the  summer  (11  June  1982, 
Julian  date  82162)  and  one  from  the  winter  (9  January  1985,  Julian  date  85009). 
AFGL  had  all  the  data  necessary  to  perform  a  hemispheric  nephanalysis  for  both 
days.  The  data  had  been  obtained  earlier  from  AFGWC  through  periodic  data  saves 
that  were  made  specifically  for  AFGL  nephanalysis  investigations  (Bunting  et  ah, 
1983).  For  each  of  the  case  study  days,  two  full  hemispheric  cloud  analyses  were 
generated  using  the  RTNEPH  and  the  AFGL  cloud  layer  algorithms  respectively. 
Results  of  the  separated  analyses  were  compared  visually  and  statistically  to 
characterize  the  differences. 

All  work  for  the  comparison  study  was  performed  on  the  AFGL  Interactive 
Meteorological  Computer  System  (AIMS).  AIMS  is  a  distributed  system  of  mini-  and 
microcomputers  and  special  purpose  imaging  computers,  all  linked  by  a  local  area 
network  (for  a  system  description  see  Gustafson,  et  al.,  1987).  AIMS  is  ideally  suited 
for  this  type  of  investigation  because  of  the  amount  of  mass  storage  available  for  the 
large  RTNEPH  data  bases,  the  inherently  interactive  hands-on  nature  of  the  system, 
and  its  extensive  image  processing  capabilities. 

This  report  describes  the  comparison  study  conducted  on  the  two  cloud  layer 
algorithms  and  characterizes  their  differences  in  terms  of  the  key  meteorological 
parameters.  The  report  concludes  with  recommendations  for  incorporating  the 
AFGL  algorithm  into  the  RTNEPH  and  with  suggestions  for  future  work  in  this  area. 
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2.  THE  AFGWC  REAL-TIME  NEPHANALYSIS 


RTNEPH  is  the  operational  realtime  cloud  analysis  model  of  the  Air  Force.  It  is 
composed  of  four  primary  modules:  the  satellite,  conventional,  merge,  and  bogus 
processors.  Each  performs  a  major  function  in  the  analysis  of  available  cloud 
observation  data. 

The  satellite  processor  generates  a  cloud  analysis  that  is  derived  from  satellite 
observations  of  cloud  cover.  Two  non-satellite  supporting  databases  required  are 
conventional  meteorological  observations  of  surface  temperatures  and  upper-air 
temperature  profiles.  These  data  are  used  by  the  satellite  processor  for  cloud 
detection  and  to  assign  cloud  top  altitudes.  The  satellite  processor  analyzes  both 
visible  and  infrared  data.  In  general,  the  darker  a  visible  grayshade  value  is,  the  less 
cloud  there  is  associated  with  that  grayshade.  Conversely,  the  higher  an  IR 
brightness  temperature  is,  the  more  likely  it  is  to  represent  a  cloud-free  area. 

The  conventional  processor  generates  a  separate  cloud  analysis  that  is  derived 
solely  from  surface,  rawinsonde,  and  aircraft  pilot  observations  of  cloud  cover  and 
weather. 

Both  the  satellite  and  conventional  processors  generate  an  individual  cloud 
analysis  for  only  those  gridpoints  where  each  has  processed  data.  The  two  analyses 
are  subsequently  combined  by  the  merge  processor  where  they  are  subjected  to 
stringent  timeliness  and  quality  checks  (Kiess  and  Cox,  1988).  The  combining  of 
these  two  databases  is  the  major  step  in  producing  the  final  RTNEPH  operational 
cloud  analysis. 

The  bogus  processor  permits  interactive  modification  of  the  merge  processor 
analysis.  Manual  corrections  can  be  made  at  locations  where  the  analysis  is 
interpreted  as  unrepresentative  of  actual  conditions.  This  judgement  is  most  often 
based  on  subjective  interpretation  of  fine-resolution  satellite  imagery  valid  for  the 
analysis  time  and  area. 

The  satellite  processor  analysis  dominates  the  merged,  pre-bogused  cloud  analysis 
since  satellite  data  are  the  only  true  source  of  global  cioud  cover  observations 
available  to  the  RTNEPH.  Infrared  data  are  the  most  frequently  processed  satellite 
data  because  they  are  available  day  and  night,  and  their  use  is  not  complicated  by 
changes  in  solar  viewing  geometry.  For  these  reasons  AFGL  devotes  its  nephanalysis 
efforts  primarily  to  studies  of  the  IR  processor,  although  future  plans  include  studies 
of  the  visible  processor. 

2.1  The  Infrared  Satellite  Data  Processor 

The  infrared  satellite  processor  generates  a  cloud  analysis  hat  is  derived  from  IR 
satellite  observations  of  cloud  cover.  These  IR  data  are  stored  in  a  regular  grid 
known  as  the  Satellite  Global  Data  Base  fSGDB);  there  is  also  corresponding  visible 
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data  in  the  SGDB.  Satellite  data  are  mapped  into  the  SGDB  as  soon  as  they  become 
available.  The  nominal  resolution  of  a  pixel  within  the  SGDB  is  3  n  mi.  The 
RTNEPH  IR  processor  produces  a  cloud  analysis  over  an  8  X  8  array  of  IR  pixels. 

The  infrared  processor  has  three  main  functions:  1)  select  a  cutoff  IR  grayshade 
that  delineates  cloudy  pixels  from  clear  pixels;  2)  perform  a  layer  analysis  on  the 
cloudy  pixels;  and  3)  determine  the  resultant  cloud  parameters.  Each  of  these  steps  is 
outlined  in  the  following  sections. 

2.1.1  RTNEPH  IR  CLOUD/NO-CLOUD  DECISIONS 

IR  grayshades  in  the  SGDB  represent  specific  temperature  ranges.  The  relation 
between  grayshade  and  temperature  is  linear:  grayshades  range  from  0  (dark)  to  63 
(bright)  and  correspond  to  temperatures  from  310  K  to  190  K,  respectively.  This 
relationship  between  grayshade  and  temperature  is  chosen  so  that  when  the 
grayshades  are  displayed,  bright  grayshades  denote  clouds  while  dark  grayshades 
denote  clear  areas.  At  AFGWC,  this  convention  is  inverted:  0  corresponds  to  190  K 
and  63  corresponds  to  310  K. 

Consider  an  8  x  8  array  comprised  of  clear  and  cloudy  pixels,  each  represented 
by  some  grayshade  G.  The  selection  of  a  cloud/no-cloud  cutoff  that  separates  the 
clear  and  the  cloudy  grayshades  is  first  made  by  determining  the  measured 
temperature  Tobg(G)  of  the  scene  being  viewed  via  lookup  tables.  Then  Tobg  and  the 
underlying  surface  temperature  Tsfc  are  compared,  where  Tgfc  is  the  temperature  that 
the  satellite  measures  if  the  scene  is  cloud-free. 

In  an  ideal  situation,  if  the  difference 

ATobs  =  Tsfc-Tobs  (1) 

is  greater  than  zero,  the  pixel  represented  by  Tobg  is  cloudy  since  the  scene  being 
viewed  has  a  lower  temperature  than  the  underlying  surface.  (This  assumes  that 
atmospheric  temperature  monotonically  decreases  with  height.)  If  ATobg  is  less  than 
or  equal  to  0,  then  the  scene  is  clear. 

However,  biases  are  present  in  the  IR  temperature  measurements.  There  are  also 
uncertainties  in  the  accuracy  of  the  surface  temperatures  that  the  RTNEPH  uses,  and 
atmospheric  water  vapo;  attenuation  cannot  be  neglected.  These  issues  complicate 
the  cloud/no-cloud  decision  defined  by  the  simple  scenario  outlined  in  Eq.  (1)  above. 
In  the  RTNEPH,  correction  factors  are  applied  to  the  measured  IR  temperature  TQbg. 
These  corrections  are  a  function  of:  1)  satellite  sensor,  to  account  for  any  biases 
inherent  in  the  sensor  construction  that  affect  its  measurements;  2)  geography  type 
and  time  of  day,  to  account  for  uncertainties  in  how  well  the  surface  temperature  Tg^ 
represents  the  background  skin  temperature;  and  3)  earth  location,  since  water  vapor 
attenuation  corrections  are  made  for  tropica!  regions. 
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The  reliability  of  the  surface  temperature  values  is  of  concern.  Surface 

temperature  fields  that  are  used  for  data-sparse  regions  have  higher  uncertainties 

than  those  collected  in  data-rich  regions.  It  is  because  of  this  uncertainty  that, 

instead  of  being  greater  than  or  equal  to  zero,  ATobg  must  be  greater  than  or  equal  to 

some  cloud  threshold  value  AT  , ,  before  the  RTNEPH  detects  cloud.  AT  , ,  is 

cJd  cld 

typically  nonzero,  varies  with  earth  location,  and  is  higher  for  data-sparse  regions  of 
the  globe  than  it  is  for  data-rich  regions.  A  higher  threshold  ATcld  forces  a  measured 
IR  temperature  Tobg  to  be  considerably  lower  than  the  surface  temperature  before 
cloud  is  detected.  In  other  words,  extra  precaution  is  taken  in  data-sparse  regions  to 
ensure  that  an  incorrect  cloud  decision  is  not  made. 

In  summary,  RTNEPH  considers  a  given  scene  to  be  cloudy  when  the 
temperature  Tobg  of  that  scene  satisfies  the  condition 

ATob3  s  ATcld,  (2) 

where  ATobg  is  given  by  Eq.  (1)  with  Tobg  corrected  for  bias  and  atmospheric  effects, 
and  where  ATc[d  is  a  predetermined  function  of  earth  location  and  time  of  day. 

2.1.2  DETERMINATION  OF  CLOUD  LAYERS 

Having  separated  out  the  cloudy  pixels  using  Eq.  (2),  the  remaining  clear  pixels 
are  excluded  from  any  further  cloud  processing.  The  cloudy  pixels  are  then  analyzed 
for  cloud  layers.  The  RTNEPH  uses  a  layer  analysis  algorithm  that  processes  a 
maximum  array  size  of  8  x  8;  the  AFGL  layer  algorithm  processes  a  16  x  16  array. 

Although  they  process  different  array  sizes,  each  algorithm  starts  its  analysis  in 
essentially  the  same  way.  From  the  original  array  of  IR  data  a  grayshade 
distribution,  called  a  histogram,  is  constructed  using  only  the  cloudy  grayshades. 
Histograms  typically  show  peaks  and  valleys  that  in  theory  separate  one  cloud  layer 
from  the  next.  An  example  of  a  histogram  is  shown  in  Figure  1. 

When  looking  at  the  histogram  it  is  sometimes  easy  to  see  in  a  subjective  sense 
where  one  cloud  layer  ends  and  another  begins,  while  at  other  times  it  is  not  so  easy. 
The  job  of  the  RTNEPH  and  AFGL  layer  algorithms  is  to  objectively  determine 
where  the  layer  grayshade  boundaries  are,  and  to  pass  this  information  on  to  the  part 
of  the  IR  processor  that  determines  layer  cloud  top  heights  and  amounts. 

There  are  subtle,  persistent  differences  in  the  way  that  each  algorithm  performs. 
The  objective  rules  that  each  algorithm  invokes  in  determining  layer  boundaries  are 
not  the  same.  How  these  differences  manifest  themselves  in  the  final  IR  processor 
output  is  the  major  issue  addressed  in  this  paper.  Detailed  outlines  of  how  each 
algorithm  works  are  beyond  the  scope  of  this  paper.  R,  lers  who  want  more 
information  about  the  AFGL  algorithm  should  refer  to  Hawkins  (1980,  1981),  and  for 
the  RTNEPH  algorithm,  to  Kiess  and  Gox  (1988). 
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Number  of  Pixels  per  Grayshade 


Grayshade 

Figure  1.  Example  of  a  Grayshade  Histogram.  The  First  Layer  (Cluster)  Lies 
Between  Grayshade  Values  8  and  16,  the  Second  Between  17  and  32,  and  the  Third 
Between  33  and  50 
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2.1.3  DETERMINATION  OF  CLOUD  AMOUNTS  AND  HEIGHTS 


Once  layer  grayshade  boundaries  are  specified,  the  cloud  amount  for  that  layer  is 
computed  by:  1)  counting  the  number  of  pixels  with  grayshade  values  that  fall 
between  the  given  layer  boundaries;  and  2)  dividing  that  count  by  the  total  number 
of  pixels  within  the  analysis  array.  In  order  to  compute  the  layer  top  height,  the 
brightest  IR  grayshade  (coldest  cloud  top)  for  the  layer  is  first  converted  to  cloud  top 
temperature  using  the  lookup  table  (see  Section  2.2).  This  temperature  is  then 
corrected  for  atmospheric  attenuation  and  satellite  sensor  biases  before  it  is  used  to 
calculate  a  cloud  height  using  the  temperature-height  profile  valid  for  the  location 
being  analyzed. 


3.  THE  AFGL  RESEARCH  AND  DEVELOPMENT  NEPHANALYSIS 

The  AFGL  research  and  development  nephanalysis  (RDNEPH)  is  the  baseline 
program  that  is  used  to  test  both  the  RTNEPH  and  AFGL  cloud  algorithms  in  a 
consistent  environment.  RDNEPH  has  four  functions:  1)  accept  user  processing 
instructions;  2)  access  the  satellite  and  supporting  data  from  the  AFGL  data  base 
that  are  required  to  perform  the  cloud  analysis;  3)  invoke  either  the  RTNEPH  or  the 
AFGL  algorithm,  and;  4)  generate  results  in  the  form  of  representative  grayshade 
(RGS)  displays  and  tabular  listings  of  total  cloud,  cloud  amount  and  height  by  layer, 
and  various  processing  parameters  and  statistics.  RGS  displays  are  synthetic  images 
that  are  produced  from  interim  results  of  both  nephanalysis  programs.  The  images 
are  used  extensively  at  AFGL  for  evaluation  (see  Section  4.1). 

Significant  differences  exist  between  the  RDNEPH  framework  and  that  of  the 
RTNEPH.  However,  considerable  care  was  exercised  to  insure  that  both  processing 
algorithms  operate  in  exactly  the  same  way  within  RDNEPH  as  they  do  at  AFGWC. 
Only  changes  that  were  necessitated  by  the  vast  differences  in  computing 
environments  between  AFGWC  and  AFGL  were  made  to  the  processing  algorithms. 
When  setting  up  the  test  environment,  data  base  considerations  were  minimized  by 
the  decision  to  retain  the  AFGWC  NEPH  grid  structure  for  use  at  AFGL.  The 
NEPH  grid  structure  is  used  operationally  at  AFGWC  to  manage  all  input  and 
output  data  associated  with  the  RTNEPH.  It  consists  of  a  series  of  nested  grids 
mapped  to  a  hemispheric  standard  polar  stereographic  projection  true  at  60°  latitude. 
The  center  of  the  projection  is  at  the  pole,  and  the  horizontal  axis  is  aligned  with  the 
10°  east  meridian.  Varying  grid  resolutions  are  computed  as  fractions  of  the  standard 
mesh  size  of  200  n  mi,  known  as  whole-mesh.  Resolution  increases  by  factors  of  two 
(that  is,  2,  4,  8,  16...)  and  the  gridpoints  are  referred  to  respectively  as  half-mesh 
boxes,  quarter-mesh  boxes,  eighth-mesh  boxes,  sixteenth-mesh  boxes,  etc.  Table  1 
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Grid  Resolutions  and  Databases  of  the  RTNEPH 

Grid  Size 

Nominal  Resolution 
(True  at  60  °) 

Types  of  Data  Available  at 

This  Resolution 

RTNEPH  Box 

1600  n  mi 

Standard  Block  of  Cloud  Analysis 

Whole-mesh 

200  n  mi 

Upper  Air  Temperature  Profiles 

Quarter-mesh 

50  n  mi 

Satellite  Times  and  Viewing  Angles 

Eighth-mesh 

25  n  mi 

Cloud  Cover  Analysis;  Surface 
Temperatures,  Terrain  Heights; 
Geography,  Background  Brightness 

Sixty-fourth- 

mesh 

3  n  mi 

Satellite  Data  in  the  SGDB 

Table  1.  Resolutions  of  the  RTNEPH  Grid  Structure.  Examples  of  RTNEPH 
Databases  That  Have  Resolutions  at  Each  Grid  Size  Are  Also  Listed 

lists  the  grid  resolutions  used  by  the  RTNEPH  data  base  (see  Hoke  et  al.  (1981)  for  a 
complete  description  of  the  NEPH  grid  structure).  It  should  be  noted  that  the  8X8 
array  used  by  the  RTNEPH  algorithm  corresponds  exactly  to  one  eighth-mesh  box  of 
satellite  data,  while  the  16  X  16  AFGL  array  is  one  quarter-mesh  box. 

3.1  AFGL  RDNEPH  Data  Processing  Design 

The  AFGWC  RTNEPH  accesses  many  dynamic  data  bases  in  realtime.  Both  the 
data  sources  and  their  valid  times  vary  significantly.  Because  it  runs  in  realtime  the 
RTNEPH  must  constantly  interpolate  supporting  data  to  the  times  of  the  satellite 
data  before  they  can  be  used  in  the  cloud  analysis.  However,  the  AFGL  RDNEPH 
has  no  realtime  constraints,  making  time-interpolation  during  execution  unnecessary. 
Free  of  this  constraint,  AFGL  was  able  to  simplify  the  complex  data  management 
functions  of  the  RDNEPH  code  by  performing  the  necessary  time-interpolations  prior 
to  runtime. 

An  AFGL  RDNEPH  data  field  represents  the  most  up-to-date  surface  or 
atmospheric  conditions  available  at  the  time  of  the  satellite  data  save.  Each 
particular  type  of  RDNEPH  data  contains  the  pertinent  and  most  timely  parts  of 
several  AFGWC  data  fields.  Among  the  RTNEPH  data  bases  that  change  with  time 
are  background  brightness,  surface  temperature,  and  atmospheric  temperature  and 
height  profiles  in  addition  to  the  visible  and  infrared  satellite  data.  Terrain  heights 
and  geography  flags  require  no  time-interpolation  for  the  RDNEPH. 

Full-page  color  enhanced  displays  of  each  hemispheric  database  are  in  Section  7, 
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Figures  12  -  19.  Since  each  display  takes  up  almost  a  full  page,  it  is  less  disruptive  to 
the  reader  and  easier  to  compare  the  displays  with  one  another  when  they  are  placed 
together  away  from  the  main  text.  All  the  figures  in  Section  7  are  cited  in  the 
following  sections.  A  description  follows  of  each  of  the  RDNEPH  databases. 

3.1.1  RDNEPH  SUPPORTING  DATA  BASES 

Surface  Terrain  Height.  Surface  terrain  heights  are  provided  for  each  eighth- 
mesh  gridpoint,  and  have  a  10  m  vertical  resolution.  Terrain  heights  are  used  to 
ensure  that  analyzed  cloud  layer  base  and  height  altitudes  are  not  below  ground  level. 
Since  terrain  heights  remain  essentially  unchanged  with  time,  the  terrain  field  for  the 
two  test  dates  are  identical.  Figure  12  shows  the  northern  hemisphere  terrain  data 
base. 

Geography  Flags.  Like  the  terrain  data,  the  geography  flags  are  also  provided 
for  every  eighth-mesh  gridpoint.  Geography  flags  indicate  whether  an  eighth-mesh 
box  is  composed  predominantly  of  water,  land,  ice,  coastline,  or  if  the  box  is  off- 
hemisphere  (as  far  as  the  grid  projection  is  concerned).  These  flags  play  a  role  in 
determining  corrections  to  measured  IR  brightness  temperatures. 

In  the  absence  of  clouds,  IR  sensors  measure  the  temperature  of  the  Earth’s 
surface.  However,  for  land  backgrounds  the  surface  temperature  database  contains 
shelter  temperatures  (that  is,  the  temperature  of  the  air  a  few  meters  above  the 
ground).  Therefore,  to  accurately  detect  cloud,  the  threshold  algorithm  (  Eq.  (2)  ) 
must  first  modify  the  shelter  temperatures  to  compensate  for  differences  that  exist 
between  the  temperature  of  the  air  and  the  underlying  surface.  These  corrections  are 
applied  as  a  function  of  geography  type.  Typically  they  are  larger  for  land 
backgrounds  than  for  water  backgrounds,  since  over  the  oceans  the  surface 
temperature  database  contains  temperatures  that  are  very  close  to  actual  sea  surface 
temperatures.  The  corrections  also  vary  with  time  of  day. 

Since  geography  fields  contain  sea  ice-cover  information,  they  vary  from  week  to 
week.  Figure  13  shows  the  geography  data  for  the  summer  and  winter  case  study 
days,  with  the  seasonal  differences  in  sea-ice  coverage  highlighted. 

Background  Brightness.  Background  brightness  is  defined  as  the  brightest 
visible  SGDB  grayshade  value  that  a  pixel  within  a  particular  eighth-mesh  box  is 
expected  to  have  when  the  pixel  is  cloud-free.  In  the  visible  satellite  data  processor, 
measured  visible  grayshade  values  are  compared  against  the  expected  background 
brightness  value  to  determine  whether  clouds  are  present  in  the  scene.  If  the 
measured  pixel  value  is  higher  than  the  background  value  by  a  pre-specified  threshold 
amount,  the  pixel  is  cloudy;  if  the  pixel  value  is  lower,  the  pixel  is  cloud-free. 

Background  brightness  values  are  used  by  the  nephanalysis  IR  processor  to  help 
determine  the  magnitude  of  the  cloud  IR  threshold  (see  Section  2.1.1).  In  general,  the 
higher  the  background  brightness  value  (that  is,  the  more  reflective  the  background), 
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the  greater  the  clear/cloud  temperature  threshold.  In  other  words,  observed  ER 
brightness  temperatures  must  be  lower  than  the  underlying  surface  temperature  by  a 
larger  amount  for  brighter  surfaces  than  for  darker  surfaces  before  the  nephanalysis 
will  detect  cloud.  The  reason  is  that  bright,  highly  reflective  cloud-free  surfaces  tend 
to  be  deserts  or  other  remote  regions  with  high  diurnal  temperature  ranges  and  very 
few  observations  of  surface  temperature.  Surface  temperature  fields  that  are  used  for 
these  data-sparse  regions  have  higher  uncertainties  than  those  collected  in  data-rich 
regions.  Adjusting  the  clear/cloud  threshold  higher  reflects  this  uncertainty,  since 
the  higher  value  forces  an  IR  temperature  to  be  definitively  lower  than  the 
background  skin  temperature  before  cloud  is  detected. 

The  background  brightness  field  is  a  dynamic  database  that  is  monitored  and 
updated  by  the  RTNEPH  in  real-time.  There  is  one  database  per  satellite.  Updates 
in  background  brightness  values  are  necessary  due  to  changes  in  snow/ice  cover  and 
vegetation  (week-to-week  variations),  solar  declination  (seasonal  variations),  and 
other  natural  effects.  Figures  14a  and  14b  contain  the  background  brightness  fields 
for  the  two  case  study  days.  Land  background  brightnesses  are  depicted  as  either  a 
shade  of  green  (lower  albedoes)  or  yellow  (higher  albedoes;  note  especially  the 
deserts).  Separate  background  brightness  values  are  used  for  snow,  ice  and  water. 
Eighth-mesh  boxes  that  contain  snow  cover  are  represented  by  white  pixels,  along 
with  ice  and  water  flags  (gray  and  blue,  respectively)  merged  in  from  the  geography 
data  base. 

In  Figure  14a,  problems  with  snow  coverage  at  lower  latitudes  are  readily 
apparent  for  the  summer  day  82162.  This  problem  is  less  evident  for  the  winter  day 
85009  shown  in  Figure  14b.  These  inaccuracies  can  adversely  affect  the  clear/cloud 
decisions  of  the  visible  and  IR  processors. 

Surface  Temperatures.  Surface  temperatures  are  available  at  eighth-mesh 
resolution.  In  the  nephanalysis,  if  the  IR  brightness  temperature  is  sufficiently  lower 
than  the  background  surface  temperature,  cloud  is  detected. 

Surface  temperature  analyses  are  available  every  three  hours  at  AEGWC.  Over 
land  areas,  surface  temperature  values  are  updated  once  every  three  hours;  over  ocean 
boxes,  temperatures  are  updated  once  every  one  or  two  days. 

For  the  82162  case  study,  surface  temperature  analysis  fields  over  land  boxes 
were  available  for  18  UTC  and  21  UTC.  In  addition,  a  three-hour  forecasted  surface 
temperature  field  with  a  valid  time  of  00  UTC  for  day  82163  was  available.  For  the 
AFGL  RDNEPH,  a  composite  surface  temperature  field  was  generated  for  day  82162 
by  time-interpolating  the  three-hour  temperature  values  to  the  actual  times  of  the  IR 
satellite  data.  Land  boxes  with  satellite  overpass  times  that  fell  outside  the  surface 
temperature  analysis  times  were  retained  in  the  composite  temperature  analysis  but 
were  excluded  from  processing  by  both  analysis  algorithms. 

All  of  the  temperature  data  for  the  water  boxes  were  one  to  three  days  older  than 
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the  corresponding  satellite  data.  However,  since  ocean  surface  temperatures  do  not 
change  significantly  on  three-day  time  scales,  all  these  data  were  accepted  for 
inclusion  into  the  82162  hemispheric  composite  surface  temperature  field  and  all  of 
these  grid  boxes  were  processed. 

A  similar  composite  temperature  field  was  produced  for  day  85009.  However,  for 
this  day,  five  analysis  times  of  surface  temperatures  were  available:  12,  15,  18,  and 
21  UTC  for  day  85009,  and  00  UTC  for  day  85010.  Since  more  surface  temperatures 
were  available,  more  satellite  data  were  processed  over  land  boxes  for  day  85009  than 
were  processed  for  day  82162.  Eighth-mesh  processing  flags  were  set  up  to  indicate 
whether  a  particular  grid  box  was  to  be  processed  (see  Section  3.1.2). 

Figures  15a  and  15c  contain  displays  of  the  composite  hemispheric  surface 
temperature  fields  used  by  the  AFGL  RDNEPH  for  days  82162  and  85009.  Note  the 
seasonal  changes  between  the  displays.  In  addition,  Figure  15b  contains  displays  of 
the  five  surface  temperature  fields  that  were  used  to  generate  the  composite  field  for 
day  85009.  Note  the  diurnal  changes  from  one  time  to  the  next. 

Temperature  Profiles.  Atmospheric  temperature  profiles  are  used  in  the 
nephanalysis  to  compute  heights  of  cloud  layers.  Having  determined  the  temperature 
of  a  given  cloud  layer  from  the  IR  processor,  a  cloud  top  altitude  is  assigned  to  that 
layer  using  the  temperature-height  profiles.  Temperature  profiles  are  at  whole-mesh 
resolution  and  are  normally  updated  from  two  to  four  times  daily.  Temperatures  and 
heights  are  given  at  ten  standard  pressure  levels:  1000,  850,  700,  500,  400,  300,  250, 
200,  150,  and  100  mb. 

3.1.2  EIGHTH-MESH  PROCESSING  FLAGS 

The  satellite  data  used  for  the  two  case  studies  in  this  comparison  investigation 
consist  of  a  “snapshot”  of  the  SGDB,  that  is,  the  SGDB  is  frozen  at  one  instant  in 
time  and  saved.  Since  the  SGDB  is  a  dynamic  data  base,  with  new  data  constantly 
being  added,  the  snapshot  necessarily  contains  satellite  data  of  varying  ages.  As 
described  in  Section  3.1.1,  surface  temperature  data  were  obtained  from  AFGWC  for 
a  number  of  different  time  periods  preceding  the  valid  time  of  the  SGDB.  To  insure 
that  the  supporting  data  (most  notably  the  surface  temperatures)  match  the  satellite 
data  temporally  at  each  quarter-mesh  box,  stringent  timeliness  checks  are  made 
among  the  various  data  sources.  The  timeliness  check  requires  that  for  land  boxes  to 
be  processed,  the  valid  time  of  the  satellite  data  at  each  quarter-mesh  box  must  fall 
within  the  times  for  which  surface  temperature  analyses  are  available.  When  this 
condition  is  met,  the  surface  temperature  values  that  bracket  the  satellite  time  are 
interpolated  to  the  satellite  time  and  stored  in  the  composite  eighth-mesh  surface 
temperature  data  file.  A  separate  field  of  processing  flags  is  maintained  concurrently 
for  each  eighth-mesh  grid  point.  These  flags  are  set  when  timely  surface  temperature 
data  is  available  for  a  given  eighth-mesh  point.  The  timeliness  criterion  is  relaxed  for 


-11- 


ocean  surfaces.  Ocean  surface  temperature  analyses  of  up  to  72  hours  prior  to  the 
satellite  valid  time  are  accepted. 

After  the  surface  temperature  data  are  analyzed  for  timeliness  and  subsequently 
interpolated,  the  background  brightness  data  are  checked  for  a  match  with  the 
satellite  ID  in  the  SGDB.  If  there  are  no  background  brightness  data  available  that 
match  the  satellite  ID  of  a  quarter-mesh  box,  all  eighth-mesh  processing  flags  within 
the  quarter-mesh  box  are  cleared.  The  processing  flags  are  checked  during  the  cloud 
analysis,  and  an  eighth-mesh  box  is  not  processed  if  the  flag  is  not  set.  The  eighth- 
mesh  processing  flag  database  is  used  only  by  the  AFGL  RDNEPH.  Figures  16  and 
18  contain  hemispheric  displays  of  the  SGDB  that  show  IR  grayshades  where  the 
eighth-mesh  flags  are  set,  and  black  where  the  flags  are  not  set. 


4.  COMPARISON  RESULTS 

The  comparison  study  of  the  RTNEPH  and  AFGL  cloud  layer  algorithms  was 
performed  using  the  hemispheric  case  study  data  described  in  Section  3.  The  two 
algorithms  under  investigation  were  run  on  the  data  for  both  days  using  the 
RDNEPH  program  to  insure  consistency.  RDNEPH  output  provides  detailed 
information  on  cloud  amount,  cloud  layer  distribution,  and  cloud  height  for  each 
analysis  box  in  the  hemisphere.  This  information  was  used  to  compute  summary 
statistics  for  the  different  analyses.  In  turn  the  statistics  were  used  to  characterize 
the  differences  between  the  two  analysis  algorithms. 

In  this  section,  the  RDNEPH  products  that  were  used  in  the  comparison  analysis 
are  described.  In  addition  the  various  statistics  that  were  used  for  characterizing  the 
algorithm  results  are  introduced.  Results  of  the  RDNEPH  runs  are  presented  for  each 
algorithm/case  study  combination. 

4.1  Representative  Grayshade  Images 

Representative  grayshade  (RGS)  images  are  synthetic  images  that  pictorially 
represent  the  cloud  analysis  of  the  IR  processor.  They  are  used  extensively  at  AFGL 
to  evaluate  visually  the  automated  RDNEPH  cloud  analyses.  RGS  images  are 
constructed  by  doing  a  pixel-by-pixel  replacement  of  the  original  SGDB  IR  image 
with  a  representation  of  the  cloud  layer  and  height  analyses  that  corresponds  to  that 
IR  image.  As  such,  RGS  images  retain  the  same  spatial  distribution  of  cloud  and 
background  features  contained  in  the  original  IR  image.  This  is  an  important 
attribute  of  the  RGS  display  since  the  eye  relies  on  recognition  of  spatial  patterns  to 
interpret  an  image. 

The  value  of  an  RGS  pixel  is  determined  through  a  series  of  tests.  If  an  IR  pixel 
is  analyzed  by  the  cloud  algorithm  as  clear,  the  RGS  is  assigned  a  reserved  value  that 
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represents  the  background  type  at  that  location  (obtained  from  the  geography  data 
base).  If  the  IR  pixel  is  cloudy,  the  RGS  is  assigned  an  intensity  value  that 
corresponds  to  the  analyzed  cloud  layer  temperature.  The  intensity  value  is  obtained 
from  the  same  grayshade-to-temperature  lookup  table  used  by  the  RDNEPH  to 
obtain  IR  brightness  temperatures  from  the  SGDB  data.  In  this  way  cloudy  portions 
of  the  RGS  image  retain  an  appearance  similar  to  the  original  ER  image. 

Once  all  the  grayshades  are  assigned  to  the  RGS  image,  the  clear  pixels  are 
color-enhanced  to  facilitate  the  easy  identification  of  the  backgrounds.  RGS  water 
pixels  are  colored  light  blue;  land  pixels  dark  green;  ice  pixels  dark  blue;  and 
coastlines  bright  green.  The  cloudy  RGS  pixels  are  enhanced  in  shades  of  gray.  The 
brighter  the  cloudy  RGS  pixel,  the  higher  the  cloud  layer.  Note  that  each  cloud  layer 
within  a  given  eighth-mesh  box  has  its  own  unique  RGS  grayshade.  Thus,  when  an 
RGS  image  is  examined,  clear  regions  (in  color)  stand  out  sharply  against  cloudy 
regions  (in  shades  of  gray).  In  addition,  multiple  cloud  layers  are  distinguishable  as 
differing  shades  of  gray.  Table  2  lists  the  values  for  RGS  grayshades.  An  example  of 
a  hemispheric  RGS  image  for  day  82162  is  shown  in  Figure  17;  for  85009,  see  Figure 
19. 


By  displaying  the  RTNEPH  or  AFGL  cloud  analyses  as  RGS  images,  cloud  layer 
details  are  seen  on  a  scale  that  is  as  fine  as  the  input  satellite  data.  RGS  images  allow 
for  a  direct,  one-to-one  comparison  between  the  SGDB  imagery  and  the  RDNEPH 
cloud  analysis  output.  Compare  the  RGS  images  in  Figures  17  and  19  with  the  SGDB 
images  in  Figures  16  and  18,  respectively.  This  type  of  visual  comparison  is  useful  for 
evaluating  the  accuracy  and  the  characteristics  of  the  NEPH  output.  Many 
important  features  that  are  lost  in  the  coarser  eighth-mesh  cloud  analysis  are  clearly 
noticeable  within  the  sixty-fourth-mesh  RGS  image. 

4.2  RDNEPH  Statistics 

Summary  statistics  of  the  RDNEPH  output  data  are  computed  and  displayed  in 
tabular  and/or  graphical  form.  These  statistical  calculations  use  as  input  the  cloud 
analysis  data  produced  by  the  RTNEPH  and  AFGL  algorithms.  The  RDNEPH 
statistics  help  quantify  the  differences  between  the  two  cluster  algorithms  and,  if 
desired,  between  the  algorithms  and  ground  truth.  Statistics  can  be  computed  for  a 
complete  hemispheric  analysis,  for  specific  RTNEPH  boxes,  for  particular  geography 
types  (for  example,  land/coast  vs.  water/ice),  for  a  specified  atmospheric  layer  (for 
example,  low,  middle,  or  high),  or  even  for  a  specific  time  of  day.  The  following  is  a 
description  of  the  statistics  that  are  generated  for  an  RDNEPH  cloud  analysis  and 
how  those  statistics  are  derived. 
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RGS  Grayshade  Values  For  Clear  Pixels 

RGS  Value 

Geography  Type 

Color  Enhancement 

0 

Off-Hemisphere 

Black 

1 

Water 

Light  Blue 

2 

Land 

Dark  Green 

3 

Ice 

Dark  Blue 

4 

Coastline 

Bright  Green 

>4 

Clouds 

Grayshades 

Table  2.  Representative  Grayshade  Values  for  Clear  and  Cloudy  Pixels 


Layer  Cloud  Amount.  The  average  cloud  amount  per  layer  “n”  (where  n 
ranges  from  1  to  4)  is  computed  by  summing  the  percent  coverage  of  each  cloudy 
layer  that  has  at  least  1  percent  cloud,  and  dividing  by  the  number  of  times  that  layer 
occurs  within  an  eighth-mesh  box.  This  calculation  can  be  done  only  for  RDNEPH 
cloud  analyses  and  not  for  cloud  truth  since  layer  information  is  not  yet  provided  as  a 
part  of  the  cloud  truth  database  (see  Section  4.3).  Figure  2  contains  examples  of  plots 
of  cloud  amount  vs.  layer  number  for  the  RTNEPH  and  AFGL  algorithms  for  the 
1982  and  1985  case  study  days. 

Layer  Frequency  Distributions.  Layer  frequency  distributions  are  built  by 
counting  the  number  of  times  layer  “n”  occurs  within  all  processed  eighth-mesh 
boxes.  The  RTNEPH  and  AFGL  algorithms  allow  up  to  a  maximum  of  four  layers. 
The  average  number  of  cloud  layers  per  eighth-mesh  box  is  also  computed  as  a 
routine  part  of  the  statistics  calculations. 

Figure  3  contains  plots  of  the  number  of  eighth-mesh  boxes  vs.  number  of  layers 
for  the  RTNEPH  and  AFGL  algorithms  for  day  82162.  Note  that  the  AFGL 
algorithm  tends  to  find  fewer  layers  than  the  RTNEPH  algorithm. 

Distribution  of  Total  Cloud  Amount  Per  Eighth-mesh  Box.  Determination 
of  the  frequency  distribution  of  cloud  amount  per  eighth-mesh  grid  box  is  also  a  part 
of  the  statistics  calculations.  The  cloud  amount  distribution  through  either  a 
specified  layer  or  throughout  the  entire  depth  of  the  atmosphere  can  be  computed. 
When  cloud  amount  distributions  for  a  layer  are  computed,  the  total  layer  cloud 
amount  is  computed  by  adding  together  the  cloud  amount  for  each  cloud  that  has  a 
top  within  that  layer.  Using  such  a  scheme,  it  is  possible  to  have  layer  cloud  amounts 
greater  than  100  percent  due  to  layer-averaging  and  roundoff  procedures  that  are  a 
part  of  the  RTNEPH. 
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Figure  2.  Plot  of  Average  Cloud  Amount  Per  Layer  for  the  RTNEPH  and 
AFGL  Algorithms 


Cloud  amount  distributions  can  be  stratified  in  several  different  ways.  For 
example,  they  can  be  computed  for  a  limited  set  of  RTNEPH  boxes  (for  example,  all 
land  or  all  water  boxes)  or  for  a  range  of  latitudes  (for  example,  for  the  tropics,  mid¬ 
latitudes,  or  polar  regions).  Figure  4  shows  the  distribution  of  eighth-mesh  boxes  as  a 
function  of  total  cloud  amount  for  the  full  hemisphere,  day  82162.  Note  the  high 
number  of  boxes  that  are  either  completely  clear  or  cloudy. 

Cloud  Amount  As  a  Function  of  Viewing  Angle.  Cloud  amount  vs.  viewing 
angle  curves  are  computed  by  mapping  the  analyzed  total  cloud  amount  to  the 
satellite  viewing  angle  for  an  eighth-mesh  box.  When  the  curves  are  generated  from 
nephanalyses  that  cover  large  regions  of  the  globe  or  that  cover  long  periods  of  time, 
they  show  biases  in  cloud  amount  as  satellite  viewing  angles  change.  Typically,  cloud 
amounts  increase  as  viewing  angle  increases  due  to  infrared  atmospheric  attenuation 
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Figure  3.  Sample  Plot  of  Frequency  Distribution  of  Number  of  Layers  for  the 
RTNEPH  and  AFGL  Algorithms 


and  cloud  geometry  considerations.  Atmospheric  attenuation  causes  a  given  scene  to 
appear  colder,  and  hence  potentially  more  cloudy,  at  higher  viewing  angles.  The 
geometrical  shapes  of  clouds  dictate  that  as  viewing  angles  increase,  less  of  the  tops 
and  progressively  more  of  the  sides  of  clouds  are  viewed  by  a  satellite  sensor.  For 
clouds  with  large  vertical  extents  in  partially  cloudy  scenes,  the  potential  exists  for 
seeing,  and  subsequently  confusing,  more  of  the  sides  of  clouds.  This  can  translate  to 
an  increase  in  analyzed  cloud  cover  even  though  the  actual  earth  cover  remains 
unchanged.  Figure  5  plots  how  cloud  cover  varies  with  viewing  angle  for  the  case 
study  day  82162.  Note  the  tendency  for  cloud  amount  to  increase  at  larger  viewing 
angles. 
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Figure  4.  Sample  Plot  of  the  Frequency 
Distribution  of  Total  Cloud  Amount 


Figure  5.  Sample  Plot  of  Total 
Cloud  Amount  vs.  Viewing  Angle 


Cloud  Height.  The  average  cloud  height  within  a  specified  atmospheric  layer  is 
computed.  These  statistics  illustrate  a  key  difference  between  the  characteristics  of 
the  AFGWC  and  AFGL  cloud  layer  analyses.  This  topic  is  discussed  in  more  detail  in 
Section  5. 

Sharpness.  Sharpness  is  the  percentage  of  eighth-mesh  boxes  that  have  total 
cloud  amounts  in  either  the  0-20  percent  range  (nominally  clear)  or  the  80  -  100 
percent  range  (nominally  overcast).  Sharpness  values  for  both  the  82162  and  85009 
case  study  days  are  approximately  85  percent  (see  Figure  4). 

4.3  Cloud  Truth  Images 

Quantitative  evaluation  of  the  accuracy  of  cloud  detection  algorithms  can  be 
problematic  due  to  the  general  lack  of  cloud  ground  truth.  Even  surface-based  cloud 
observations  are  difficult  to  use  because  of  the  radically  different  viewing  geometries 
of  a  surface  observer  and  a  satellite.  In  an  effort  to  make  some  type  of  quantitative 
estimate  of  the  cloud  detection  accuracy  of  the  two  algorithms  under  investigation 
here,  manual  cloud  analyses  were  made  for  selected  RTNEPH  boxes  for  use  as  ground 
truth.  The  manual  analyses  were  generated  from  the  same  SGDB  visible  and  infrared 
data  used  by  the  automated  algorithms.  To  aid  image  interpretation,  the  full  range 
of  image  processing  and  display  functions  of  the  AIMS  imaging  computer  system  were 
used. 

The  procedure  for  generating  manual  cloud  analyses  on  AIMS  is  a  well  defined 
iterative  procedure  designed  to  produce  an  optimal  analysis  given  the  quality  of  the 
data  (see  Gustafson  and  Felde,  1988;  1989).  First,  both  the  infrared  and  visible 


-17- 


imagery  for  a  selected  RTNEPH  box  are  displayed.  The  analyst  selects  a  subregion  of 
the  box  for  analysis.  The  data  from  one  or  both  of  the  satellite  channels  for  the 
selected  subregion  are  isolated  and  loaded  onto  a  clear  screen  on  the  display  device. 
Different  interactive  contrast  enhancements  and  display  options  can  be  applied  to  the 
imagery  to  help  the  analyst  identify  the  cloud  boundaries.  Cloud  boundary  location 
is  then  transferred  into  a  digital  file  in  the  computer  through  a  process  known  as 
threshold  blanking.  Threshold  blanking  is  an  interactive  technique  that  allows  for 
very  accurate  selection,  isolation  and  extraction  of  cloud  features  that  the  analyst  has 
identified  visually.  The  procedure  is  repeated  for  different  sub-regions  of  the 
RTNEPH  box  until  the  analyst  is  satisfied  that  all  cloud  boundaries  have  been 
accurately  identified.  The  manual  analysis  is  stored  as  a  synthetic  binary  image  that 
can  be  directly  compared  to  the  automated  analysis.  At  AFGL  these  synthetic 
images  are  referred  to  as  cloud  truth.  Statistical  evaluations  of  the  agreement 
between  the  automated  analyses  and  cloud  truth  can  be  used  to  provide  a 
quantitative  measure  of  the  cloud  detection  accuracy. 

Midway  through  the  term  of  this  comparison  study  a  change,  known  commonly 
as  the  sharpness  fix,  was  made  in  the  RTNEPH  cloud  detection  procedure  at 
AFGWC.  Recall  from  Section  2.1.2  that  the  RTNEPH  layer  analysis  combines  pixels 
of  an  8  X  8  IR  array  into  thermally  homogeneous  clusters.  Before  the  sharpness  fix 
was  incorporated  into  the  RTNEPH,  the  cloud  layer  analysis  would  be  performed  on 
the  complete  IR  array,  even  though  the  pixels  often  represent  a  mix  of  clear  and 
cloudy  scenes.  The  clear/cloud  decisions  were  then  made  on  a  cluster-by-cluster 
basis,  rather  than  on  a  pixel-by-pixel  basis.  This  offered  the  potential  for 
misinterpreting  some  pixels  depending  on  how  well  the  algorithm  segregated  clear 
and  cloudy  pixels  into  separate  clusters.  For  example,  if  a  cluster  contains  both  clear 
and  cloudy  pixels,  then  an  error  in  total  cloud  amount  would  always  be  incurred  by 
the  RTNEPH  because  that  cluster  is  flagged  as  either  completely  clear  or  completely 
cloudy.  Hence  differences  in  the  way  each  algorithm  performed  the  cluster 
separations  resulted  in  differences  between  the  total  cloud  amounts  detected  by  the 
RTNEPH  and  AFGL  algorithms. 

However,  the  sharpness  fix  reversed  the  order  of  processing,  so  that  the 
clear/cloud  decision  is  now  made  prior  to  the  layer  analysis  (refer  to  paragraph  1  of 
Section  2.1.2).  This  means  that  all  clear  pixels  are  removed  from  consideration  before 
being  processed  by  the  layer  algorithm.  As  expected,  sharpness  was  smaller  in  every 
instance  (that  is,  with  the  sharpness  fix)  by  an  average  of  6  percent. 

Before  comparing  the  RTNEPH  and  AFGL  layer  analyses,  the  sharpness  fix  was 
incorporated  into  both  programs.  One  of  the  consequences  of  this  fix  is  that  the 
differences  between  the  ways  the  RTNEPH  and  AFGL  cloud  algorithms  perform 
cloud  detection  are  eliminated.  As  a  result,  the  total  cloud  amounts  computed  by 
each  algorithm  are  equal,  although  significant  differences  remain  in  the  cloud  layer 
results.  After  the  changes  were  implemented  in  the  AFGL  test  programs,  cloud 
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detection  accuracy  was  removed  as  a  comparison  criteria  as  far  as  this  study  is 
concerned.  However,  it  is  still  of  interest  to  compare  analyzed  cloud  amounts  with 
cloud  truth  images  to  determine  how  accurate  the  automated  analysis  is. 

Figure  6a  shows  an  RGS  image  (see  Section  4.1)  for  RTNEPH  Box  45  taken  from 
the  82162  case  study.  The  corresponding  visible  and  infrared  satellite  data  are  shown 
for  reference  in  Figures  6c  and  6d.  Figure  6b  contains  a  truth  image  which  is 
interpreted  in  the  same  way  as  the  RGS;  color-enhanced  pixels  represent  clear  regions 
while  cloudy  areas  are  in  shades  of  gray.  By  comparing  RGS  and  truth  images  it  is 
easier  to  visualize  how  the  RTNEPH  and  the  AFGL  algorithms  perform  relative  to 
truth  and  relative  to  each  other.  Although  not  required  of  this  study,  such 
comparisons  will  be  useful  in  future  nephanalysis  studies  that  deal  with  viewing  angle 
bias  and  the  improved  detection  of  low  clouds  and  thin  cirrus. 
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Figure  6a.  RGS  Cloud  Analysis  Image  for  RTNEPH  Box  45,  Summer  Day  82162. 
Color-enhanced  pixels  denote  clear  regions,  and  gray  pixels  denote  clouds 
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Figure  6b.  Cloud  Truth  Image  for  RTNEPH  Box  45,  Summer  Day  82162.  Color- 
enhanced  pixels  denote  clear  regions,  and  gray  pixels  denote  clouds 
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Figure  6c.  Visible  Image  for  RTNEPH  Box  45,  Summer  Day  82162.  Bright  tones 
denote  high  solar  reflectance;  dark  tones  denote  low  reflectance 
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Figure  6d.  Infrared  Image  for  RTNEPH  Box  45,  Summer  Day  82162.  Bright  tones 
denote  low  brightness  temperatures;  dark  tones  denote  high  temperatures 
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5.  DISCUSSION 


The  results  of  the  RTNEPH  and  AFGL  layer  analyses  are  presented  in  the 
following  sections.  The  layer  analyses  are  not  precisely  as  they  would  be  in  the 
operational  AFGWC  RTNEPH  cloud  analysis  because  merge  processing  of  the  cloud 
data  has  been  excluded;  that  is,  the  results  presented  here  were  generated  by  the  IR 
processor  only.  However,  these  results  allow  for  interesting  and  valuable  comparisons 
between  the  AFGL  and  RTNEPH  layer  algorithms,  and  highlight  characteristic 
differences  between  the  two  that  would  be  observed  if  each  were  a  merged 
nephanalysis. 

5.1  Cloud  Layers 

Tables  3  and  4  summarize  the  nephanalysis  cloud  layer  statistics  by  background 
type  and  algorithm.  The  data  in  Table  3  for  summer  show  higher  cloud  amounts  and 
more  cloud  layers  for  both  algorithms  than  the  data  shown  for  winter  in  Table  4.  The 
statistics  also  indicate  a  consistently  different  distribution  of  layer  frequencies  for  the 
RTNEPH  and  AFGL  algorithms.  The  column  headed  “Layer  Frequency  (percent )” 
gives  the  distribution  of  the  number  of  layers  found  per  eighth- mesh  box.  For  the 
RTNEPH  algorithm,  Table  3  shows  for  land/coast  backgrounds  that  13  percent  of 
the  time,  one  cloud  layer  was  found  in  an  eighth-mesh  box;  20  percent  of  the  time, 
two  were  found;  15  percent  of  the  time,  three  were  found;  and  50%  of  the  time,  four 
were  found.  (The  percentages  do  not  usually  sum  to  100  since  they  are  truncated  to 
whole  numbers  when  they  are  computed.)  Note  that  four  cloud  layers  are  found  by 
the  RTNEPH  algorithm  more  frequently  than  three  cloud  layers.  All  of  the  other 
RTNEPH  layer  frequencies  in  Tables  3  and  4  share  this  unusual  distribution,  with 
lower  frequencies  of  three  cloud  layers  than  of  either  four  or  two.  There  is  no 
apparent  explanation  for  this  distribution  either  in  the  logic  of  the  RTNEPH 
algorithm  or  in  the  literature  of  cloud  observations. 

The  AFGL  algorithm,  on  the  other  hand,  has  a  layer  frequency  distribution  that 
is  consistently  smoother  than  that  of  the  RTNEPH  algorithm,  as  can  be  seen  in 
Tables  3  and  4.  The  AFGL  distribution  has  a  peak  frequency  for  two  cloud  layers  in 
summer  (Table  3)  and  for  one  cloud  layer  in  winter  (Table  4).  The  frequencies 
decrease  for  three  and  four  cloud  layers. 

The  difference  in  the  RTNEPH  and  AFGL  layer  frequency  distributions  are  also 
shown  in  the  plots  of  Figure  7  for  the  summer  and  winter  cases.  There  is  a 
substantial  difference  in  the  number  of  times  that  the  RTNEPH  and  AFGL 
algorithms  find  four  cloud  layers  —  38  percent  compared  to  8  percent  for  summer, 
and  18  percent  compared  to  2  percent  for  winter.  The  higher  frequency  of  four  cloud 
layers  in  the  RTNEPH  contributes  to  a  higher  average  number  of  layers  per  eighth- 
mesh  box;  2.10  for  AFGL  compared  to  2.69  for  RTNEPH  in  summer,  a  28  percent 
increase;  and  1.64  for  AFGL  compared  to  1.97  for  RTNEPH  in  winter,  a  20  percent 
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Table  3.  IR  Processor  Hemispheric  Statistics  for  the  Summer  Case  Study  Day  82162 
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Table  4.  IR  Processor  Hemispheric  Statistics  for  the  Winter  Case  Study  Day  85009 


Normalized  Frequency 


82IH2  CI.OUD  l-AYKIi  FREQUENCY  DISTRIBUTION 
RTN  EPII  AFGL 


j  ..  !  • 

|  |  |  1 

;»aaa  ■* ■  . x.. i  .  . . a -i 

1  ?  3  *  1  ■?  3  4 

Number  of  Cloud  Layers 


86010  CLOUD  LAYER  FREQUENCY  DISTRIBUTION 


60  | - 

RTNEPH  AFGL 


Figure  7.  Plots  of  Layer  Frequency  as  a  Function  of  the  Number  of  Cloud 
Layers  for  the  RTNEPH  and  AFGL  Algorithms  (See  Tables  3  and  4  -  Layer 
Frequency  Statistics) 


increase.  RTNEPH  tends  to  find  more  cloud  layers  than  AFGL.  This  results  in  a 
significantly  cloudier  RTNEPH  because  of  the  upper  cloud  occlusion  algorithm  that  is 
a  part  of  the  merge  processor.  The  cloud  occlusion  algorithm  increases  the  lower- 
layer  cloud  amounts  by  5  -  10  percent  for  each  layer,  which  would  cause  significant 
differences  between  the  final  cloud  analyses  of  the  RTNEPH  and  AFGL  algorithms. 

Tables  3  and  4  cover  all  cloud  top  heights.  Tables  7-12  were  generated  for  the 
low  (0  -  2000  m),  middle  (2001  -  6000  m),  and  high  (6001  -  22500  m)  ranges  of  cloud 
top  height  (see  Section  8).  Within  each  range,  the  RTNEPH  algorithm  finds  small 
frequencies  of  occurrence  (5  -  10  percent)  of  three  or  four  cloud  layers,  while  the 
AFGL  algorithm  rarely  finds  more  than  two.  The  average  number  of  cloud  layers 
within  each  range  of  cloud  heights  is  consistently  greater  for  the  RTNEPH  algorithm. 
These  results  suggest  that  the  tendency  of  the  RTNEPH  algorithm  to  find  more  cloud 
layers  than  the  AFGL  algorithm  is  independent  of  cloud  altitude  and  does  not  favor 
any  cloud  type. 

Comparison  of  the  layer  frequency  distributions  between  the  RTNEPH  and 
AFGL  algorithms  reveal  essentially  the  same  results  as  the  earlier  comparison  study 
between  the  3DNEPH  and  AFGL  algorithms  (d’Entremont  et  al.,  1982).  In  that 
study  both  algorithms  had  a  tendency  to  find  more  cloud  layers  than  were  identified 
by  satellite  meteorologists  who  made  a  subjective  assessment  of  infrared  and  visual 
pictures  supplemented  by  surface  reports.  Assessments  o.  the  pictures  rarely 
indicated  the  presence  of  three  or  four  cloudy  layers.  The  AFGL  algorithm  was 
preferred  since  it  was  less  likely  to  overestimate  the  number  cloud  layers.  It  is 
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preferred  now  for  the  same  reason. 

5.2  Cloud  Heights 

Average  cloud  heights  are  given  in  the  last  column  of  Tables  3  and  4.  For  the 
summer  case  study  day  (Table  3)  over  all  types  of  backgrounds,  the  RTNEPH  gives 
an  average  cloud  height  of  4252  meters,  which  is  246  meters  less  than  the  average 
cloud  height  found  by  the  AFGL  algorithm.  For  the  winter  day  (Table  4),  the 
RTNEPH  average  height  is  4206  meters,  which  is  399  meters  less  than  the  AFGL 
algorithm.  The  average  difference  between  the  RTNEPH  and  AFGL  cloud  heights  is 
equivalent  to  roughly  one  infrared  grayshade  value.  This  is  because  one  grayshade 
represents  a  temperature  range  of  1.9  K  and  atmospheric  temperatures  decrease  by 
this  amount  when  altitudes  increase  by  300  meters,  excepting  inversions. 

From  summer  to  winter,  changes  in  average  cloud  heights  for  the  RTNEPH 
algorithm  are  on  the  order  of  50  m;  the  same  is  true  for  the  AFGL  algorithm.  The 
50  m  change  is  surprisingly  small,  considering  that  tropopause  heights  and  cirrus 
cloud  heights  tend  to  be  1  -  2  km  lower  in  the  winter  over  much  of  the  hemisphere. 
The  explanation  is  that  the  winter  case  had  fewer  low  clouds  than  the  summer  case  as 
can  be  seen  in  Figures  8  to  11. 

Figures  8  to  11  show  the  height  distribution  of  average  cloud  amount  and  number 
of  layers  for  the  five  layers  of  5LAYER,  the  main  cloud  forecast  model  at  AFGWC 
(Crum,  1987).  The  5LAYER  produces  cloud  forecasts  at  the  gradient  level  and  the 
850,  700,  500  and  300  mb  levels.  The  altitude  ranges  for  each  of  these  layers  are 
listed  in  Table  5. 

Figures  8  and  9  show  the  RTNEPH  and  AFGL  results  for  the  summer  case. 
Results  are  stratified  by  latitude  into  tropical,  mid-latitude,  and  polar  regions.  The 
latitude  bounds  for  these  regions  change  seasonally;  the  bounds  for  the  summer  and 
winter  case  study  days  are  the  same  as  those  used  by  the  RTNEPH,  and  are  listed  in 
Table  6.  The  lower  set  of  bar  graphs  in  Figure  8  shows  how  all  the  cloud  tops  found 
by  the  RTNEPH  are  distributed  among  the  5LAYER  layers.  For  example,  the  mid¬ 
latitude  graph  shows  that  35  percent  of  the  cloud  tops  found  by  the  RTNEPH  fall 
within  the  700  mb  layer.  The  upper  set  of  bar  graphs  in  Figure  8  plots  average  cloud 
amounts  per  layer.  These  are  computed  by  summing  the  observed  cloud  percentages 
within  the  five  defined  layers  and  dividing  by  the  total  number  of  eighth-mesh  boxes 
for  the  latitude  band.  For  mid-latitudes,  the  average  cloud  amount  in  the  700  mb 
layer  is  25  percent. 

The  distributions  of  average  cloud  amount  in  Figures  8  (for  the  RTNEPH 
algorithm)  and  9  (for  AFGL)  are  unusual  in  two  respects.  The  500  and  300  mb 
layers  include  an  altitude  range  suitable  for  nearly  all  cirrus  clouds  at  all  latitudes, 
but  have  significantly  lower  cloud  amounts  than  published  climatologies  using  surface 
or  satellite  observations  would  indicate  (Hall  et  al.,1984;  Izumi,  1982;  Hahn  et  al., 
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5LA  YER 
Layer  # 

— 

Centroid 

Pressure 

Height  Range 
(meters) 

1 

2 

3 

4 

5 

"Gradient” 

850  mb 

700  mb 

500  mb 

300  mb 

0-987 

988  -  2235 

2236  -  4239 

4240  -  7369 

7370  -  22500 

Table  5.  Altitude  Ranges  for  the  Layers  of  the  5LAYER  Cloud  Forecast  Model 


Region 

Season 

Latitude  Bounds 

Tropics 

Summer 

0°  -29.9° 

Winter 

0°  -23.5° 

Mid-Latitude 

Summer 

29  9°  -  72.9° 

Winter 

23  5°  -  66.5° 

Polar 

Summer 

72.9°  -  90  0° 

Winter 

_ 

66.5°  -  90.0° 

Table  6.  Latitude  Bounds  for  the  Tropics,  Mid-latitudes,  and  Polar  Regions  for 
the  Summer  and  Winter  Case  Study  Days 
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Figure  8.  Plots  of  Hemispheric  Cloud  Layer  Distributions  and  Average  Layer 
Cloud  Amounts  as  a  Function  of  Height  for  the  RTNEPH  Algorithm,  Summer  Day 
82162  (See  Table  13) 

1982;  Woodbury  and  McCormick,  1983).  These  sources  give  cirrus  frequencies  of 
occurrence  that  range  from  30  percent  to  60  percent  (when  sub-visual  cirrus  was 
included)  for  mid-latitude  and  sub-polar  regions  during  the  summer.  The  cloud 
amount  in  the  300  mb  layer  is  only  9  percent  for  the  RTNEPH  mid-latitude  summer, 
yet  the  altitude  range  of  that  layer  should  include  most  cirrus  clouds  in  the  mid¬ 
latitude  summer.  The  AFGL  algorithm  (Fig.  9)  found  10  percent  for  the  mid-latitude 
summer.  We  attribute  the  small  cloud  amounts  found  in  the  300  mb  layer  to 
optically  thin  cirrus  that  appears  warmer  to  the  infrared  sensor  than  the  ambient 
atmospheric  temperature  at  cirrus  altitudes.  These  clouds  tend  to  be  assigned  lower 
altitudes  by  the  ER  satellite  processor.  In  Figures  8  and  9  it  is  seen  that  the  average 
cloud  amounts  in  the  300  mb  layer  change  as  expected  in  going  from  the  tropics  to 
polar  regions,  since  the  amount  of  high  clouds  consistently  decreases  with  latitude  as 
the  tropopause  lowers. 
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Figure  9.  Plots  of  Hemispheric  Cloud  Layer  Distributions  and  Average  Layer 
Cloud  Amounts  as  a  Function  of  Height  for  the  AFGL  Algorithm,  Summer  Day 
82162  (See  Table  14) 


The  other  unusual  aspect  of  Figures  8  and  9  is  the  peak  in  average  cloud  amount 
for  the  700  mb  layer  in  the  mid-latitudes.  Higher  cloud  amounts  would  be  expected 
in  the  two  lowest  layers  (deBary  and  Moller,  1963)  or  in  the  cirrus  layer,  but  not  in 
the  middle  layer.  One  possible  explanation  is  that  the  average  cloud  amount  for  the 
middle  layer  is  enhanced  by  cirrus  clouds  assigned  to  the  wrong  layer. 

The  most  remarkable  feature  of  Figures  8  and  9  is  how  little  difference  there  is 
between  the  RTNEPH  and  AFGL  algorithms  when  the  cloud  tops  are  grouped  into 
the  5LAYER  layers.  For  the  500  and  300  mb  layers  the  AFGL  algorithm  found 
cloud  amounts  that  are  within  4  percent  of  the  corresponding  RTNEPH  cloud 
amounts.  The  greatest  difference  between  the  algorithms  is  found  in  the  gradient 
layer  of  the  tropics  where  the  cloud  amount  decreases  from  16  percent  for  RTNEPH 
to  12  percent  for  AFGL.  In  other  latitudes,  the  RTNEPH  algorithm  has  gradient 
layer  cloud  amounts  1  percent  greater  than  the  AFGL  algorithm. 
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Figure  10.  Plots  of  Hemispheric  Cloud  Layer  Distributions  and  Average  Layer 
Cloud  Amounts  as  a  Function  of  Height  for  the  RTNEPH  Algorithm,  Winter  Day 
85009  (See  Table  15) 


The  distribution  of  cloudy  layers  shown  in  the  lower  parts  of  Figures  8  and  9  are 
also  nearly  identical  for  the  RTNEPH  and  AFGL  algorithms,  even  though  the 
RTNEPH  algorithm  found  significantly  more  layers.  For  example,  RTNEPH  found  a 
total  of  251,333  layers  in  the  tropics  while  AFGL  found  only  186,403.  However,  both 
algorithms  have  nearly  the  same  distribution  of  cloud  layers  as  a  function  of  height. 
This  means  the  excess  cloud  layers  found  by  the  RTNEPH  algorithm  must  be 
proportionally  distributed  among  the  five  layers. 

Figures  10  and  11  show  the  results  for  the  winter  case.  The  cloud  layer 
distributions  are  rather  uniform  except  for  the  300  mb  mid-latitude  and  polar  layers. 
The  average  cloud  amounts  are  less  than  the  summer  values  in  every  instance  except 
for  the  700  and  500  mb  layers  at  polar  latitudes.  As  in  the  summer,  the  cloud 
amount  averages  in  the  500  and  300  mb  layers  are  lower  than  climatological  averages 
of  cirrus  clouds  and  the  same  explanation  (optically-thin  cirrus)  likely  applies. 
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Figure  11.  Plots  of  Hemispheric  Cloud  Layer  Distributions  and  Average  Layer 
Cloud  Amounts  as  a  Function  of  Height  for  the  AFGL  Algorithm,  Winter  Day  85009 
(See  Table  16) 


The  amount  of  low  clouds  at  mid-latitudes  differs  from  deBary  and  Moller  (1963) 
since  both  RTNEPH  and  AFGL  amounts  increase  with  altitude.  The  RTNEPH  and 
AFGL  results  are  in  remarkably  close  agreement  as  is  evidenced  by  intercomparing 
Figures  10  and  11. 


6.  CONCLUSIONS  AND  RECOMMENDATIONS 

A  series  of  comparison  tests  were  run  between  the  RTNEPH  and  AFGL  layer 
algorithms.  Results  show  that  the  AFGL  algorithm  finds  fewer  cloud  layers  than  the 
RTNEPH.  Interactive  interpretation  of  satellite  pictures  rarely  indicates  the  presence 
of  three  or  four  cloudy  layers  within  an  eighth-mesh  box.  The  AFGL  algorithm  is 
preferred  since  it  is  less  likely  to  overestimate  the  number  of  cloud  layers.  The  results 
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also  suggest  that  the  tendency  of  the  RTNEPH  algorithm  to  find  more  cloud  layers 
than  the  AFGL  algorithm  is  independent  of  cloud  altitude  and  does  not  favor  any 
cloud  type. 

The  IR  processors  of  both  algorithms  find  similar  cloud  heights  and  amounts. 
The  AFGL  algorithm  gives  slightly  higher  heights  and  average  cloud  amounts  in  the 
highest  altitude  ranges.  The  RTNEPH  tends  to  find  significantly  more  cloud  layers, 
but  the  layer  distribution  over  height  is  very  nearly  the  same  as  for  AFGL.  These 
results  are  interpreted  as  a  tendency  for  the  RTNEPH  algorithm  to  find  more 
structure  in  a  cloud  layer,  and  to  find  several  slightly  different  cloud  tops  where  the 
AFGL  algorithm  might  find  only  one. 

Results  also  show  that  the  average  cloud  heights  assigned  by  the  AFGL  algorithm 
are  higher  on  average  than  those  for  RTNEPH.  The  RTNEPH  cloud  heights  are  used 
to  place  analyzed  clouds  within  one  of  five  layers  in  the  5LAYER  cloud  forecast 
model.  Thus,  a  change  in  analyzed  cloud  heights  will  affect  a  change  in  how  the 
5LAYER  moisture  field  is  initialized,  subsequently  affecting  the  model  results.  The 
differences  between  the  RTNEPH  and  AFGL  cloud  heights  are  small  with  respect  to 
the  5LAYER  layers,  preliminarily  indicating  that  a  noticeable  effect  on  the  5LAYER 
cloud  forecast  would  not  be  observed. 

When  the  cloud  fields  of  the  RTNEPH  and  AFGL  algorithms  are  displayed  as 
grayshades  on  the  AIMS,  they  are  remarkably  similar.  The  clear  and  cloudy  regions 
have  identical  shapes  since  the  clear/cloud  decision  is  the  same  for  both  algorithms. 
The  cloud  temperatures  found  by  the  AFGL  algorithm  are  about  one  grayshade 
higher  than  the  RTNEPH  cloud  temperatures,  so  that  the  AFGL  cloud  fields  appear 
very  slightly  colder.  They  also  appear  more  uniform  since  the  AFGL  algorithm  gives 
fewer  layers. 

Although  in  general  there  is  little  difference  between  the  RTNEPH  and  AFGL 
algorithms  when  the  cloud  tops  are  grouped  into  the  5LAYER  layers,  the  RTNEPH 
tends  to  find  an  unrealistically  larger  number  of  cloud  layers  than  AFGL.  This  results 
in  a  cloudier  RTNEPH  because  of  the  upper  cloud  occlusion  algorithm  that  is  a  part 
of  the  RTNEPH  merge  processor.  The  occlusion  algorithm  increases  the  cloud  cover 
of  the  lower  layers  that  were  analyzed  by  the  IR  processor,  because  it  assumes  that 
they  are  obscured  from  satellite  view  by  the  higher  layers.  Thus,  since  RTNEPH 
finds  more  layers,  it  will  generate  an  analysis  that  is  more  cloudy  than  the  AFGL 
algorithm.  In  turn,  the  5LAYER  RTNEPH  moisture  initialization  field  is  likely  to 
contain  higher  humidity  values  than  the  AFGL  field,  hence  affecting  the  5LAYER 
cloud  forecast. 

To  sum  up,  the  AFGL  algorithm  gives  a  slightly  more  realistic  cloud  analysis  at 
no  additional  computational  cost.  The  comparison  tests  did  not  reveal  any  algorithm 
behavior  that  would  harm  the  RTNEPH  and  it  is  recommended  for  global 
applications. 
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7.  RTNEPH  HEMISPHERIC  DATABASE  DISPLAYS 


Full-color  displays  of  the  RTNEPH  hemispheric  databases  (Figures  12  -  19)  are 
presented  on  the  following  pages.  Figure  captions  are  self-explanatory,  and  list  the 
section  and  page  number  where  each  figure  is  first  referenced. 
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igure  12.  Northern  Hemisphere  Terrain  Heights,  in  Feet  ASL  (See  Section  3.1.1,  Page  9) 
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'igure  13.  Geography  Flags  for  the  Summer  and  Winter  Case  Study  Days  (See  Section  3.1.1,  Page  9) 
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Figure  14a.  Background  Brightness  for  the  Summer  Day  82162  (See  Section  3.1.1,  Page  10) 
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Figure  14b.  Background  Brightness  for  the  Winter  Day  85009  (See  Section  3.1.1,  Page  10) 
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Figure  15a.  Composite  Surface  Temperature  Field  for  the  Summer  Case  Study  Day  82162  (See  Section  3.1.1,  Page  11) 
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Figure  15c.  Composite  Surface  Temperature  Field  for  the  Winter  Case  Study  Day  85009  (See  Section  3.1.1,  Page  11) 
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Figure  17.  Hemispheric  Representative  Grayshade  Image  for  the  Summer  Case  Study  Day  82162  (See  Section  4.1,  Page  13) 


Figure  18.  Infrared  Satellite  Global  Data  Base  Image  for  the  Winter  Case  Study  Day  85009  (See  Section  3.1.2,  Page  12) 


8.  RTNEPH  AND  AFGL  CLOUD  ANALYSIS  STATISTICS 


RTNEPH  and  AFGL  cloud  analysis  statistics  are  presented  in  Tables  7  ig. 
Table  captions  are  self-explanatory,  and  list  the  section  and  page  nuinuer  where  each 
table  is  referenced. 
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Table  7.  IR  Processor  Hemispheric  Statistics  for  the  Summer  Case  Study  Day  82162,  Low  Clouds 
(See  Section  5.1,  pg.  27) 
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Table  9.  IR  Processor  Hemispheric  Statistics  for  the  Summer  Case  Study  Day  82162,  High  Clouds 
(See  Section  5.1,  pg.  27) 
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Table  10.  ER  Processor  Hemispheric  Statistics  for  the  Winter  Case  Study  Day  85009,  Low  Clouds 
(See  Section  5.1,  pg.  27) 
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Table  11.  ER  Processor  Hemispheric  Statistics  for  the  Winter  Case  Study  Day  85009,  Middle  Clouds 
(See  Section  5.1,  pg.  27) 
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Table  12.  IR  Processor  Hemispheric  Statistics  for  the  Winter  Case  Study  Day  85009,  High  Clouds 
(See  Section  5.1,  pg.  27) 
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13.  Cloud  Layer  Distribution  and  Average  Layer  Cloud  Amounts  for  the  RTNEPH  Algorithm,  Day  82162 
(See  Figure  8;  see  also  Section  5.1,  pg.  27) 
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Tropical  Mid-Latitude  Polar 
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Tropical  Mid-Latitude  Polar 
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